fix(call): restore Bluetooth audio routing - #6567

Thank you for contributing @flake92 🙏

It would be great if the new java class could be converted to kotlin.
Feel free to also have a look at the review from Claude AI.

Just let us know if you want to do this (that would be awesome!) or if we should take over.

Claude AI review:

Correctness (4 findings)

• No audio route for ~4s on a failed device switch (WebRtcAudioManager.java:366): if the user taps Earpiece while on Bluetooth and the switch transiently fails, the rollback-to-Bluetooth logic can't actually restart Bluetooth (it's mid-teardown), leaving the call with silence until the async disconnect settles.
• Audio-focus flapping bypasses the retry cap (WebRtcBluetoothManager.java:255): reassertBluetoothAudioAfterFocusGain() resets the SCO attempt counter on every focus-gain event, so MAX_SCO_CONNECTION_ATTEMPTS isn't actually a bound over a call's lifetime if focus flaps repeatedly (e.g. notification sounds).
• Stale getter can resurrect a route the user just left (WebRtcBluetoothManager.java:1174): a queued Bluetooth callback after an explicit clear can fall back to getCommunicationDevice(), which the code's own comment says is stale on some Samsung devices — risk of Bluetooth "coming back" after the user switched away.
• Wired-headset detection is inconsistent between two gates (WebRtcAudioManager.java:513): matchesAudioDevice() recognizes more USB/wired types than hasWiredHeadset() does, so the newer, broader matching is currently dead code — a latent trap if either is edited independently later.

Efficiency/simplification/reuse (6 findings) — lower severity: exhausted retries keep re-triggering startScoAudio() harmlessly forever; the legacy vs. Android-12+ paths are interleaved via SDK-version branches across ~11 call sites instead of being split behind an interface (real maintenance risk going forward); some duplicated device-enumeration logic between WebRtcAudioManager and ModernBluetoothRoute; one dead code branch; one needless one-line wrapper.

The two "removed behavior" concerns I'd have flagged up front — un-stickying Bluetooth selection on disconnect, and a possible SCO_DISCONNECTING race in requestBluetoothAudioSelection() — were investigated and ruled out: the first is the intentional point of the fix, the second self-heals within the 4s timeout.

Given this is call-audio-routing code (hard to unit test end-to-end, easy to regress silently), I'd suggest at minimum fixing the first two correctness findings before merging, and manually testing the "switch away from Bluetooth mid-call" and "notification during a Bluetooth call" paths on a real device.